1. Field of the Invention
The present invention relates to systems, methods and programs in the field of integrating object technology with database technology in a client/server environment, and more specifically, building objects by a query engine in response to a query by retrieving results from a database or other data source, and returning handles to application objects as query results for further use as such by the application.
2. Description of the Related Art
Databases are computerized information storage and retrieval systems. A relational database management system (RDBMS) is a database management system (DBMS) which uses relational techniques for storing and retrieving data. Relational databases are organized into tables which consist of rows and columns of data. The rows are formally called tuples. A database can have many tables and each table can have multiple tuples and multiple columns. The tables are typically stored on random access storage devices (DASD) such as magnetic or optical disk drives for semi-permanent storage.
A DBMS is structured to accept commands to store, retrieve, and delete data. One widely used and well known set of commands is called the Structured Query Language (SQL). The current SQL standard is known informally as SQL/92. The definitions for SQL provide that a DBMS should respond to a particular query with a particular set of data given a specified database content, but the method that the DBMS uses to actually find the required information in the tables on the disk drives is left up to the DBMS. There can be more than one method that can be used by the DBMS to access the required data. The DBMS will optimize the method used to find the data requested in a query in order to minimize the computer time used and, therefore, the cost of doing the query.
In object-oriented databases (OODB), the database is organized into objects having members that can be pointers to other objects. The objects contain references, and collections of references, to other objects in the database, thus leading to databases with complex nested structures.
A query can declaratively specify the contents of a view. For relational databases, a view is essentially a virtual table having virtual rows and virtual columns of data. Although views are not directly mapped to real data in storage, views can be used for retrieval as if the data they represent is actually stored. A view can be used to present to a user a single logical view of information that is actually spread across multiple. tables.
Object oriented (OO) views provide a similar service for object data as relational views do for relational data. An OO view is an alternative way of looking at data in objects contained in one or more queryable collections. An OO view is a named specification of a virtual result collection. Similarly to relational views, the bodies of some OO views in some OO systems can be queries that declaratively specify the contents of the view. In contrast with relational schemas, OO schemas are defined with a rich set of types that include multivalued attributes such as collections. These types directly model hierarchical and many-to-many relationships in the application's schema. For example, a department has a set of employees, an employee has a set of children, and so on.
Objects and Views are further discussed in the following:
"Updating Relational Databases through Object-Based Views";
Thierry Barsalou, Arthur M. Keller, Niki Siambela, Gio Wiederhold; Proc. ACM-SIGMOD International Conference on Management of Data, Denver, June 1991. PA1 If V is a view type, the object building procedure call used to build V has arguments whose ordering is that of elements in the FROM clause of M. If the ith element in the FROM clause is a view type, then a handle on the binding to the ith element is passed as an argument to the object building procedure call. (In the examples below, the build_object function is used for this purpose.) PA1 If V is a view type and the ith element in the FROM clause of M is a relational table, the object building procedure call used to create V has as its ith element a row type that is passed as an argument to the call. The row type is a generic type that is built based upon the schema of a database row. The order of arguments is given by the order of columns present in the row type.
"The MultiView OODB View System: Design and Implementation;" Harumi A. Kuno and Elke A. Rundensteiner; University of Michigan Technical Report CSE-TR-241-95.
"Object Views: Extending the Vision"; Sandra Heiler, Stanley Zdonik; Proc. IEEE International Conference on Data Engineering 90, April 1990.
"Objects and Views"; Serge Abiteboul, Anthony Bonner; ACM-SIGMOD International Conference on Management of Data, ACM 2/91.
"On View Support in Object-Oriented Database Systems"; Won Kim, William Kelley; Modern Database Systems: The Object Model, Interoperability, and Beyond, Part 1/Next-Generation Database Technology, chapter 6, 1995.
"Towards Heterogeneous Multimedia Information Systems: The Garlic Approach"; M. J. Carey, L. M. Haas, P. M. Schwarz, M. Arya, W. F. Cody, R. Fagin, M. Flickner, A. W. Luniewski, W. Niblack, D. Petkovic, J. Thomas, J. H. Williams and E. L. Wimmers; Proc. 1995, IEEE Workshop on Research Issues in Data Engineering, Taipei, Taiwan, March 1995.
"Queries and Views in an Object-Oriented Data Model;" U. Dayal; Proc. 2nd International Workshop on Database Programming Languages; editors, Richard Hull, Ron Morrison, and David Stemple, Gleneden Beach, June 1989.
The integration of object technology and database systems has been an active area of research for the past decade. One important aspect of the integration of these two technologies is the provision of efficient, declarative query interfaces for accessing and manipulating object data. Compared to other aspects of object-oriented database (OODB) technology, such as integrating persistence into object-oriented languages like C++ and Smalltalk, queries were given relatively little attention in the early days of OODB research. See "Third Generation Data Base System Manifesto, Mike Stonebraker et al, Computer Standards & Interfaces, Dec. 12, 1991. In "Object-Oriented Database Systems: Promise, Reality, and Future," Won Kim, Proc. 19th International Conference on Very Large Data Bases, Dublin, August 1993, it is pointed out that most commercial OODB systems are quite weak in this regard. As the OODB field has developed, however, a number of proposals for OODB query languages have appeared in the database literature including the following:
"A Data Model and Query Language for EXODUS," Proc. ACM-SIGMOD International Conference on Management of Data, Carey, Michael; DeWitt, David; Vandenberg, Scott; Chicago, June 1988.
"A Model of Queries for Object-Oriented Databases," Kim, Won; Proc. 15th International Conference on Very Large Data Basses, Amsterdam, August 1989.
"A Query Language for the O.sub.2 Object-Oriented Database System," Bancilhon, Francois; Cluet, S.; Delobel, C.; Proc. 2nd International Workshop on Database Programming Languages, Hull, Richard; Morrison, Ron; Stemple, David, editors; Gleneden Beach, June 1989, Morgan-Kaufmann Publishers, Inc.
"Query Processing in the ObjectStore Database System," Orenstein, Jack; Haradhvala, Sam; Margulies, Benson; Sakahara, Don; Proc. ACM-SIGMOD International Conference on Management of Data, San Diego, June 1992.
"CQL++: A SQL for a C++ Based Object-Oriented DBMS," Dar, S.; Gehani, N.; Jagadish, H.; Proc International Conference on Extending Data Base Technology, Advances in Database Technology-EDBT '92. Lecture Notes in Computer Science, Vienna, 1992. Springer-Verlag.
"Querying Object-Oriented Databases," Kifer, Michael; Kim, Won; Sagiv, Yehoshua; Proc. ACM-SIGMOD International Conference on Management of Data, San Diego, June 1992.
"Object Query Language," Atwood, Tom; Duhl, Joshua; Ferran, Guy; Loomis, Mary; Wade, Drew; Object Database Standards: ODMG-93 Release 1.1, R. G. G. Cattell, editor, Morgan-Kaufmann Publishers, Inc., 1993.
"Experiences building the open oodb query optimizer," Blakeley, Jose; McKenna, William J.; Graefe, Goetz, Proc. ACM SIGMOD International Conference on Management of Data, Washington, D.C., May 1993.
For example, O2 and ObjectStore (ObjectStore is a trademark of Object Design, Inc.) each provide their own flavor of an object query language. ObjectStore's query language is an extension to the expression syntax of C++. O2's query language is generally more SQL-like, and has been adapted into a proposed OODB query language standard (OODMG-93) by a consortium of OODB system vendors, but it differs from SQL in a number of respects. (See, "Object Query Language," Atwood, T.; Duhl, J.; Ferran, G.; Loomis, M.; and Wade, D.; Object Database Standards:ODMG-93 Release 1.1, Cattell, R. C. G., editor, Morgan-Kaufmann Publishers, Inc., 1993; and "Observations on the ODMG-93 Proposal, " Kim, W., ACM SIGMOD Record, 23(1), March 1994.)
Another aspect of integrating object technology and database systems has been the building of objects from relational data. Persistence Software, Inc., provides an Object Builder for generating snap-in database objects which map relational database information into an object application. (See, "Enabling the Integration of Object Applications with Relational Databases"; Persistence Software, Inc.; http://www.persistence. com/persistence/pageTwo. pages/techoview.htn; 4/2/97 1:40PM.)
Data Access Builder (DAX), which is a part of IBM VisualAge for C++ tools, is a GUI application that will connect to DB2 relational databases. For a certain set of tables, DAC will build C++ class definitions for rows in the table. Data can then be retrieved using a "Find By Key" function. For example, given an employee it will generate a C++ class having name, number and salary. One can issue a "Find By Key" functional call to retrieve the data for an employee, e.g., employee number 25.
An ObjectStore gateway, DB Connect, is a relational database gateway for the ObjectStore OODBMS from Object Design, Inc. (ODI). This product retrieves data from a relational database into an object-oriented database.
In summary, relational database management systems (RDBMSs) store data in tables that can be queried using languages like SQL. Tables can be defined intentionally using views. Instead of explicitly storing a set of rows, a view derives its contents from other views and tables. Users express queries over views in the same way that they express queries over tables. A view uses a query to specify its contents. A view facility can provide a similar service for Object-Oriented DBMSs (OODBMSs) as it does for relational DBMSs (RDBMSs).
Contrary to an to a RDBMS, an OODBMS manipulates application types in a seamless integration of programming language types and database types. Therefore, handles on application objects in the programming language environment can be returned as query results from an OODBMS. However, since views are derived types manipulated by the DBMS, queries cannot return handles to views as application types.
Relational databases have views that can be queried in a similar fashion as tables are queried. Likewise, it is desirable to be able to query object views in object oriented databases in a manner similar to querying objects. However, a problem exists because object-oriented databases can return handles on application objects, but if a view is to be returned, the object for the view does not exist and therefore its handle cannot be returned.
For example, in a relational database management system, if there is a table of "Employees" and a user wanted a view of "high salaried employees" called "RichEmployee" where employee salary is greater than 100,000, then the "RichEmployee" view can be manipulated in the same manner as the table "Employee" can be manipulated. However, the view "RichEmployee" is only known by the database, i.e., the user never gets a handle on any of the high salaried employee objects. The user only gets returned the attributes requested. In contrast, in an object-oriented database management system, besides getting the attributes, e.g., name, number, and salary, the user can also get a handle on the actual object. As such, the database object and the application object are really the same, and the user can get handles on them. As described, the implementation of views suffer problems because views are virtual, i.e., they don't actually exist. As long as the user performs the typical relational operations on views that will retrieve just the fields from the "RichEmployee" view, e.g., number, name, and salary, the user will not have any problems. However, the user can not get a handle on the "RichEmployee" view and therefore can not perform other operations on this view, e.g., run methods that may involve other data outside of the framework of the "RichEmployee" view.
As with any database management system such as object-oriented or relational, query rewrite transformations and system-managed query optimization are essential features to ensure acceptable query performance. Query rewrite transformations for optimizing queries have been developed previously for relational DBMSs. See "Extensible/Rule Based Query Rewrite Optimization in Starburst," Hamid Pirahesh, Joseph M. Hellerstein, and Wagar Hasan, In Proc. ACM-SIGMOD International Conference on Management of Data, San Diego, June 1992; "Magic is Relevant," Inderpal Singh Mumick, Sheldon J. Finkelstein, Hamid Pirahesh, and Raghu Ramakrishnan, In Proc. ACM-SIGMOD International Conference on Management of Data, pages 247-258, Atlantic City, May 1990; and "The Magic of Duplicates and Aggregates," Inderpal Singh Mumick, Hamid Pirahesh, and Raghu Ramakrishnan, In Proc. 16th International Conference on Very Large Data Bases, Brisbane, August 1990. Many of these transformations also apply for Object Query Systems. However, new query rewrite transformations that apply specifically to Object Query Systems still need to be developed. See "A General Framework for the Optimization of Object-Oriented Queries," Sophie Cluet and Claude Delobel, In Proc. ACM-SIGMOD International Conference on Management of Data, San Diego, June 1992.